Day 1：AI 負責答，我負責讓答案可信——一個公部門工程師的協作紀律

一個關於 NULL 的下午

先說一件小事。

某次我在處理一個從 Sequelize 4.x 升到 6.x 的舊專案，想確認一個行為：當查詢條件裡帶進一個 undefined 的值時，新舊版本的處理方式有沒有差。這件事很關鍵，因為舊程式碼裡到處都是「參數可能有、也可能沒有」的動態查詢，如果升版後行為變了，等於整個查詢邏輯都要重新檢視。

我問了 AI。它給了一個看起來很合理的答案：「新版會忽略這個條件。」

聽起來沒問題，我差點就接受了。但我追問了一句：「是『忽略』，還是『視為 NULL 來查詢』？這兩件事差很多。」

AI 順著我的話改口，說是後者，會被當成 IS NULL 處理。

這個答案更糟，因為它聽起來更專業、更具體——但我心裡的警報反而響了。一個 AI 在我輕輕一推之下就改變了技術判斷，這代表它兩次裡至少有一次是在猜。於是我說了一句話，這句話後來成了我跟 AI 協作的預設習慣：

「不要順著我的話說。請實際去確認。」

於是我沒有再跟它爭論，而是要它把對應版本的原始碼行為攤開來看。這一看，得出的結論跟它前面兩個答案都不一樣：那個條件會被組成 = NULL——一個在 SQL 語意上永遠不成立、但又不會報錯的條件。它既不是「忽略」，也不是「IS NULL」，而是一個會靜默地讓查詢結果永遠為空的陷阱。（我是怎麼一步步逼到這個真相的，明天 Day 2 會完整拆解。）

這個結論如果沒查出來，會在生產環境變成一個非常難抓的 bug：沒有錯誤訊息、沒有例外，只是查詢莫名其妙查不到資料。

這個系列想談的，不是「AI 能幫你做什麼」

過去一年，關於 AI 能做什麼的文章已經夠多了。這個系列想談的是另一面。

我是一名全端工程師，主力 Node.js，日常工作有很大一部分是承接公部門的系統專案。這類專案有幾個共同特徵：系統通常有十年以上的歷史包袱、技術債層層堆疊、資料表命名和商業邏輯充滿「當年的原因」；同時它又受到嚴格的資安合規約束——弱點掃描、組態基準、稽核軌跡，每一項都不能開玩笑。它還有一個最現實的限制：它是對民眾提供的正式服務，不太容許你拿它來試錯。

在這種環境裡用 AI，跟在一個乾淨的新專案裡用 AI，是完全不同的兩件事。

新專案裡，AI 猜錯了，你重跑一次就好。但在一個牽動實際業務、背後有合規壓力的系統裡，AI 給你一個「聽起來很專業但其實是猜的」答案，而你照單全收，代價可能是一個上線後才爆發的資料錯誤，或是一份在稽核時站不住腳的判斷。

所以這 30 天，我想誠實地記錄一件事：在一個有歷史包袱、有合規壓力、不容許出錯的真實專案裡，人跟 Claude 怎麼分工，才能真的達到 1 + 1 大於 2。 不是「Claude 能取代我多少」，也不是「我得多提防它」，而是——它負責什麼、我負責什麼，這條線畫在哪，加成才會發生。

為什麼是「紀律」，而不是「技巧」

開頭那個 NULL 的故事，重點不在 Sequelize，也不在那個特定的 bug。重點在於那句「不要順著我的話說，去確認」——以及那句話背後的分工。

先講一個事實：AI 的錯誤和它的正確，讀起來一模一樣自信。它不會在猜測時降低語氣，也不會在確定時特別強調。這不是在說 AI 不好——它生成答案的能力已經很強了，那是它的「1」。問題在於，「這個答案到底可不可信」這道關卡，它自己過不了，因為它分不出自己是在查證還是在揣測。

而這道關卡，正是人能補上的地方。這就是我想談的協作分工：AI 負責把答案生出來，人負責讓那個答案變得可信。 前者是 AI 的強項，後者是人的價值。一個工程師 + 一個 AI，之所以能做到比各自單獨更多——那個「多出來的部分」，幾乎都產生在人守住的這些關卡上：

• 什麼時候該逼它去實際驗證，而不是接受它的記憶
• 什麼時候該用自己踩過的坑去反向壓測它的建議
• 怎麼設計**人在迴路（human-in-the-loop）**的分工，讓 AI 做它擅長的、人守住它守不住的關口
• 甚至包括很現實的：token 是有成本的，什麼時候值得讓它讀更多、什麼時候該精簡

這些不是「防 AI 的技巧」，是「讓協作產生加成的紀律」。AI 只會越來越強——正因為如此，人「怎麼正確駕馭它」只會越來越重要，不會越來越不重要。能力越大的工具，落在沒有紀律的手上，闖的禍也越大。這 30 天想談的，就是那套讓 1 + 1 大於 2 的紀律。

接下來 30 天會有什麼

這個系列大致分成四個階段：

心法與定位——先把幾個核心觀念講清楚：為什麼要逼 AI 驗證、怎麼判斷不同工具（對話、程式代理、協作工具）各自的邊界、以及 human-in-the-loop 為什麼是分工設計而不是口號。

生產環境實戰——一系列真實案例：AI 畫不出台灣也判斷不了浮水印的生成極限、一個 build 設定長出兩千多層資料夾的破壞性意外、看似正確卻會拖垮資料庫的並行寫法、大型日誌檔的分析、難以重現的資料撞號 bug。這些都是在真實系統裡發生過的問題，我會完整記錄 AI 給的第一個答案、我為什麼沒有直接採用、以及最後怎麼一起收斂到真正的根因。

資安合規下的協作——這是公部門專案最特殊的一塊。弱點掃描到底有沒有意義、哪些安全標頭值得認真做哪些是掃描器的規則誤用、程式碼掃描工具的誤判怎麼處理、組態基準導入時哪些該開例外。這部分會談一個很少被公開討論的現實：「程式碼在技術上正確」和「通過稽核」有時候是兩件事。

方法論沉澱——最後把前面散落的實踐收攏成一套可複用的方法：怎麼用一份專案規範文件當成 AI 的「專案憲法」、怎麼在多個工作階段之間維持共享的記憶、怎麼寫交辦內容讓程式代理少踩坑、以及什麼時候該果斷地開一個新的工作階段。

一個前提

這個系列裡的所有案例都來自真實專案，但我會把所有能指向特定單位的資訊去掉——具體的機關、網域、內部 IP、可辨識的資料表都會被替換或抽象化，只保留技術上的重點。原因很簡單：這些系統背後是實際的公共服務，公開它們的細節對任何一方都沒有好處。我想分享的是方法和判斷，不是任何特定系統的內部樣貌。

如果這 30 天裡，有任何一篇讓你在跟 AI 協作時多停頓了三秒、多問了一句「你這是查過的，還是猜的？」，那這個系列就值得了。

明天開始，從第一個核心習慣談起：怎麼逼 AI 去驗證，而不是接受它的記憶。